Images can be more than half of the data that makes up a typical website. Although there are tools that may automatically reduce the size of the images on behalf of the website owner, many of the images may not be needed for the page as they may never be seen by the user. For example, some pages are longer than the viewport of the device (a window or other viewable area on the screen) and require the user to scroll to view the entire page. An example of such a page is a blog, which typically is a relatively long page with a series of stories, the most recent of which are on top. When the page is loaded, only the images within the viewport (the visible portion of the client window) can be viewed. However, most client network application such as browsers download all of the images on the page before the page is ready. This may slow down page performance and waste bandwidth for images that may never be seen (e.g., if the user does not scroll down to actually view the images that are not on the viewport).
Most client network applications create an image placeholder for each single image that is referenced in a web page. Most images are externally sourced and downloaded by the client network application and are displayed in the location of the corresponding image placeholders. If an image cannot be displayed (e.g., an error occurred when the image was attempted to be downloaded), most client network applications display a broken image or other error display in the location of the corresponding image placeholder.
Image loading by itself does not block client-side scripts (e.g., JavaScript) from executing. However, image loading may block the firing of the ‘onload’ event. An ‘onload’ event is typically used within the <body> element of a page and executes a client-side script once a web page has completely loaded all the content including images, script files, style files, etc. One slow image loading can delay the ‘onload’ event long enough to create user-visible lag in web page rendering.
One technique for responsive image loading includes ‘capturing’ the Document Object Model (DOM). In this technique, document.write is used in the Head tag of the page to encapsulate all of the subsequent HTML in a Plaintext node. Then the rest of the DOM is parsed as text and feed back to component modules that manipulate it. For example, a component module may convert all image ‘src’ attributes to a desired value based on the detected properties of the client browser. The manipulated DOM is then passed back to document.write and a fresh document is created from it. Although this technique provides website authors much more control over the way a page is parsed, it essentially co-opts parsing of the DOM from the browser and re-implements it in JavaScript. This can result in unexpected (or even negative) behavioral and performance-related side-effects. It also creates additional execution overhead and it occurs on the browser's user interface (UI) thread. This technique also creates difficulty in examining and debugging because one must consider the implementation of ‘capturing’ the DOM as well as the considering the underlying browser.